Multimedia service may include interactive services such as a video call, a streaming service such as transmission of Video on Demand (VoD) files, and a multicast and a broadcast service. Real-time multimedia service can be classified into conversational service, interactive service, and streaming service, according to service types. The real-time multimedia service can also be classified into unicast, multicast and broadcast services according to the number of users participating in the service.
To provide multimedia service, a network may provide Quality of Service (QoS) largely in three ways: Best Effort (BE), per class QoS, and per flow QoS. No support is given to guarantee the QoS of BE service. Per-class QoS service prioritizes packets and processes packets according to their priority levels in the network. That is, the QoS of a packet is controlled according to the importance, i.e. priority level of the packet, irrespective of a flow to which the packet belongs. Accordingly, there is no need for reserving resources between a transmitter and a receiver in order to support per-class QoS. For reference, priorities may be categorized into loss priority and delay priority.
Resources are reserved per stream in per-flow QoS service. That is, resources, e.g., a bit rate and a buffer status, or QoS, e.g., a delay, a loss rate, etc., is reserved for each flow. A flow refers to a stream used to provide a service. For instance, a video stream, an audio stream, and a text stream used to provide a VoD service are individual flows. Per-class QoS and per-flow QoS are supported in a 3rd Generation Partnership Project (3GPP) Universal Mobile Telecommunications Standard (UMTS) standard, which may also be referred to as 3G, as well as in the Institute for Electrical and Electronics Engineers (IEEE) 802.16 standard, which may also be referred to as Wireless Broadband (WiBRO) and Wireless Interoperability for Microwave Access (WIMAX) and Long Term Evolution (LTE) standards. However, a media layer being a higher layer should be interfaced with a network being a lower layer in order to use the QoS schemes.
Conventionally, Real-time Transport Protocol (RTP) and Real Time Transport Protocol (RTCP) are designed to measure network resources or QoS using information accumulated at service ends without taking into account a lower layer. In the related-art RTP and RTCP, a network part responsible for transmission is kept as a black box and thus it is difficult to accurately identify any change. Therefore, an interface directed immediately from the lower layer should be used for accurate QoS control. In Moving Picture Experts Group (MPEG)-2 and H.264, particularly Scalable Video Coding (SVC), each video packet is different in terms of importance. The importance difference between packets should be identified in order to effectively control the QoS of a video service. To determine the importance of each packet in Internet Protocol (IP) version 6 (IPv6), in a case of packet switching, five tuples, those being a receiver address, a transmitter address, a port number of a service in a receiver, a port number of the service in a transmitter, and a used protocol, should be read from an IPv6 header and then header data representing the importance of the packet should be read from a payload of a video packet. This scheme takes a lot of processing time per packet and violates the independence of a protocol layer.
That is, a router should be able to read only an IP header of a packet in processing the packet, but it does not actually. If the importance of each packet can be readily determined, then the router can actively perform QoS control. For example, if a network state is poor, then the router may discard an unimportant packet first according to the per-packet importance. Meanwhile, SVC or Multi-view Video Coding (MVC), which is under standardization, is based on the H.264/Advanced Video Coding (AVC) standard. Coded data is constructed into a bit stream in the Network Abstraction Layer (NAL) Unit (NALU) format of H.264/AVC.
FIG. 1 illustrates a Video Coding Layer (VCL) and NAL of H.264/AVC according to the related art.
Referring to FIG. 1, in H.264/AVC, a NAL 120 is defined between a VCL 110 that handles video coding and a lower-layer system 130 that transmits and stores the coded information. Thus, the VCL 110 is separated from the NAL 120. The NAL 120 processes coded data 111 generated from the VCL on a NALU basis in order to map the coded data 111 to bit streams of the lower-layer system 130 in a format, such as an H.264/AVC file format 131, an RTP 133, and an MPEG-2 system 135.
NALUs are divided into a VCL NALU 121 and a non-VCL NALU 123. The VCL NALU 121 is a NALU corresponding to the coded data 111 generated in the VCL 110 and the non-VCL NALU 123 is a NALU corresponding to a parameter set, Supplemental Enhancement Information (SEI), or similar information. A NALU includes a NAL header and a Raw Byte Sequence Payload (RBSP) which is a data part resulting from video coding of the VCL.
FIG. 2 illustrates a format of a NALU according to the related art.
Referring to FIG. 2, a NALU 200 includes a NAL Header 210 and NALU Payload 240. The NAL Header 210 typically occupies 1 to 5 bytes. The NAL Header 210 includes NALU Type Information 220 indicating a type of the NALU and Layer Identification Information 230 indicating the layer of compressed original data included in the NALU Payload, i.e. a combination of a priority, a spatial-layer level, a temporal-layer level, and/or a quality-layer level. The NALU Type Information 220 includes a Fixed-bit (F) field 221, a nal_ref_idc (NRI) field 222 being a flag indicating whether the NALU is a reference picture, and a NALU Type field 223 indicating the type of the NALU.
The Layer Identification Information 230 includes a Priority (P) field 231 indicating the priority of the NALU so that the layer of the compressed original data can be identified, a Dependency_id (D) field 232 indicating the spatial-layer level of the NALU, a Temporal_level (T) field 233 indicating the temporal-layer level of the NALU, and/or a Quality_level (Q) field 234 indicating a quality-layer level of the NALU. The same NALU format is used in MVC. In MVC, however, the NALU Type Information 220 and View Identification Information, which indicates a View instead of the Layer Identification Information 230, may be included in the NAL Header.
According to the foregoing NALU format for SVC or MVC, the Layer Identification Information 230 or View Identification Information of the NAL header should be parsed in order to identify the layer or view of the NALU. Particularly, the Layer Identification Information 230 is 2 to 4 bytes long and all of the values of the P, D, T and Q fields 231 to 234 should be determined by parsing the NAL Header 210. Parsing of the entire NAL header 210 to detect the values of the P, D, T and Q fields 231 to 234 imposes a constraint on a processor and increases system cost.
Moreover, the NAL Header 210 includes information from which the importance of a packet may be determined, such as the P field 231. However, since a router processes a packet after reading only an IP header, it may not read the importance identification information from a NALU header. Accordingly, there exists a need for including importance identification information in an IP header so that a router may read the importance identification information.